本文是「Agent 开发实践与思考」系列第 19 篇。系列目录：
- 2024
- 2025
- 01-28 长任务不失忆：上下文压缩、交接文档与子任务隔离
- 02-25 MCP 用了三个月：工具标准化之后 Agent 设计变了什么
- 03-25 拆解 Coding Agent：为什么”写代码 + 文件系统”是通用 Agent 的内核
- 05-13 Agent 如何用代码完成推理、校验、适配与展示
- 06-03 能看会说的 Agent：语音交互与 Computer Use 这半年
- 06-24 从同步问答到事件驱动：异步 Agent 的架构改造笔记
- 07-08 没有评估就没有迭代：我的 Agent 评估落地记
- 09-09 后训练扫盲：SFT 记知识、RL 学长处，和 Agent 有什么关系
- 10-01 AI Coding 的上下文摘要：几家产品到底在压缩什么
- 10-14 让 Agent 从经验里长本事：失败复盘、经验库与提示词自动优化
- 11-04 能力按需加载：从动态提示词到 Agent Skills
- 11-25 多 Agent 协作的真实收益与代价（本篇）
多 Agent 的适用条件
上下文隔离适用于会产生大量中间产物的子任务。例如调研任务会产生网页全文、搜索结果和试错记录，主对话通常只需要结论。压缩可以减少上下文占用，但会丢失部分信息；后续需要被压缩掉的内容时，无法从摘要中恢复。隔离则将完整中间产物保留在子 Agent 的上下文和文件中，不放入主对话。
我在长任务那篇写的子任务隔离，是多 Agent 的一种实现：将子任务交给拥有独立上下文的 Agent 执行，只将结论返回主对话。主对话的上下文容量有限，这是拆分 Agent 的直接原因。
专长分工适用于生成和评审可以使用不同提示词或模型的任务。评审 Agent 不接收生成过程时，不受生成过程中的推理路径影响，更容易独立发现问题。让同一个 Agent 检查自己的产出时，它可能延续此前的推理路径，影响评审结果。
并行执行适用于相互独立的任务，可以减少墙钟时间。我曾对三个技术方案做调研：每项约需八分钟，串行执行约二十四分钟，并行执行并合并整理后不到十分钟。前提是任务之间确实独立。若第二个任务依赖第一个任务的结论，并行执行会产生基于猜测的中间结果，合并时可能需要返工。
常用组织模式及限制
管理者模式由一个 lead 分派和汇总任务，是我目前的默认模式。它明确了分工和责任归属，但 lead 的上下文会成为限制：所有子任务的结论都回流到这里。任务增加后，lead 可能遗漏约束或此前的任务说明。
我遇到过一次这样的情况：lead 管理四个子任务，执行到后半程时遗漏了最早交给第一个子任务的边界条件。收到的结果格式不一致，只能重新分派部分任务。对此，lead 只接收结论和文件路径，不接收过程；过程由子 Agent 写入文件。lead 的上下文只保留任务清单和状态，不存放细节。
对等模式没有 lead，多个 Agent 直接相互交付任务。这种模式需要明确异常分支的责任归属。我曾让两个 Agent 处理一个工单流：A 负责分类，B 负责起草回复。分类置信度低时的处理方式虽然写入了提示词，但 A 假定 B 会处理，B 假定 A 会升级，最终这批工单没有被处理，日志中分别记录为“对方负责”。对等模式中，每个任务必须指定唯一 owner，并将其写入消息结构，不能依赖隐含约定。
流水线模式在同一上下文中依次切换角色提示词，例如先以产品经理角色编写需求，再以工程师角色实现，最后以测试角色检查。它不需要启动多个进程。限制是后续角色能读取前序角色的完整推理过程，测试角色可能延续工程师的思路，降低发现问题的概率。角色之间需要共享大量背景时可以使用流水线；需要独立评审时，应隔离生成和评审的上下文。
Agent 间的通信内容
在这类项目中，我优先传递文件路径，而不将大段内容直接放入消息。文件系统可以作为共享产物存储，拆解 Coding Agent 那篇讨论过这种用法。子 Agent 将中间产物写入文件，交接时传递路径和摘要。这样可以减少消息占用的上下文；出现问题时可以查看原始版本；多个下游也可以读取同一份文件，无需在消息中复制内容。很短且需要立即确认的状态则适合直接传递结构化内容，具体选择取决于运行时和一致性要求。
将大段内容放入消息会增加上下文和版本管理成本。消息历史通常不会随文件更新自动同步；下游继续使用消息中的副本时，可能读取过期版本。因此需要使用版本号、校验和或重新读取文件来确认状态。
交接消息应使用结构化字段。自由文本交接容易遗漏约束：上游写了三段话，下游模型可能只采用最后一句。我使用的交接消息包含任务 ID、输入文件、产出文件、状态、置信度和给下游的注意事项。置信度影响下游是否可以直接采用该产出。增加这些字段的成本较低，可以减少“上游说明不完整”造成的交接问题。
并发与错误传播
两个 Agent 修改同一文件时，若没有锁、版本检查或合并策略，后写入的结果可能覆盖先写入的结果；另一个 Agent 也可能继续基于过期状态工作。单 Agent 通常较少发生并发写入，多 Agent 会增加这种情况的出现机会。可以按文件分工，也可以使用锁、版本检查或明确的合并策略，不能只依赖运行时协调。
A 的判断错误后，B 可能将其当作事实继承，B 的结论再传给 C，多个环节后结果可能逐步偏离。每次交接都会增加错误被复制和放大的机会。跨 Agent 传递结论时，应尽量附带置信度、出处或验证状态，并在关键节点重新校验。
“这个接口支持分页（我读过分页的实现）”和“这个接口应该支持分页”提供的证据不同。前者可以直接采用，后者需要先验证。没有出处的结论，下游需要重新验证。
A2A 的协议范围
Google 在 2025 年 4 月发布了 A2A（Agent2Agent）协议，目标是让不同厂商、不同框架的 Agent 相互发现并协作。其设计包含 Agent Card、任务生命周期和 artifact 等概念，传输层使用 HTTP 与 JSON-RPC。它和 MCP 的常见分工是：MCP 主要描述 Host、模型与工具或资源之间的连接；A2A 主要描述 Agent 之间的任务委派、状态同步和产物交付。实际边界还取决于协议版本和具体实现。MCP 我在二月那篇写过，它解决互操作问题，不负责替模型选择正确的工具；A2A 也解决互联互通，不保证协作质量。
我的判断是，企业内部跨厂商 Agent 协作目前还不普遍。多数团队内部的多个 Agent 尚未形成稳定的编排方式。可以关注协议本身，但是否引入应由实际的跨 Agent 协作需求决定。
斯坦福小镇的实验范围
2023 年的斯坦福小镇实验包含 25 个 Agent，它们在模拟小镇中活动，并组织了一场情人节派对。该实验展示了多 Agent 的社会行为，也影响了后续关于“多 Agent 涌现”的讨论。
实验在模拟环境中观察多 Agent 的社会行为。派对是实验中的行为结果，实验没有将其定义为交付物。实验也未包含生产系统通常要求的截止时间、验收标准和责任归属。因此，它不能单独证明这种组织方式适合生产任务。
分工、接口和责任边界
多 Agent 系统需要明确分工、接口和责任边界。系统是否会主动汇报进度、识别缺少 owner 的任务，或质疑不明确的交接方式，取决于提示词、编排逻辑和运行时能力，不能默认系统会完成这些动作。设计不清时，Agent 可能更快地执行错误流程。
我的优先级是先完善单 Agent 的上下文管理、工具和评估；在出现上下文隔离、专长分工或独立任务并行等条件时，再拆分 Agent。拆分后，任务要有唯一 owner，交接消息要结构化，结论要附带出处。这些要求来自组织协作本身，在 Agent 系统中同样适用。
